restaurer nand

Déjà repondu en partie à cette question et inutile de la poser sur tous les sujets.
Tu peux utiliser n'importe quel hack pour ta console si tu le souhaites. Il suffit de choisir sur lequel tu souhaites boot. D'ailleurs il me semble qu'avec le dongle SX Pro, il y des possibilités également comme avec d'autres. Tu peux aussi utiliser ton PC pour booter sur un hack.

Dans tous les cas, je te laisse consulter les tutoriels. D'ailleurs si tu as une sauvegarde de ta NAND, pourquoi ne pas la restaurer via Hekate et ensuite mettre à jour en 9.2.0 pour utiliser à nouveau SX OS ?

SX OS n'est toujours pas porté pour HOS 10.0.
Si tu as pu redémarrer ta console normalement, c'est que le mode autoRCM n'est pas actif ou alors il manque un détail dans ton explication. Et si tu n'as pas de sauvegarde de ta NAND pour la restaurer, oui tu peux tester un autre hack mais à toi de voir.

Cette option est active par défaut et cela est précisé dans notre tutoriel de la désactiver si active.
underground-switch/utiliser-choidujournx-t744482.html
Donc je ne sais pas quel tutoriel tu as suivi auparavant.

Du coup, il te faudrait utiliser Hekate pour désactiver ce mode autoRCM si actif et éventuellement restaurer ta NAND si tu en avais fait une auparavant pour profiter à nouveau du Hack.

Salut à toi,
J'ai trouvé mon bonheur via Wii U nand Extractor, (ton deuxième lien)
Je lui ait fait charger le slc.bin et vais dans le dossier "sys" (ca ne peut pas être ailleurs)
Mais il n'y a pas de "syshax.xml" mais le "system.xml" est bien présent. (rapport avec la version du dump faite en 5.5.1 ?)
tu as un screenshot de l'arborescence de fichiers ici :

Enfin voilà mon system.xml (rappel : sans CBHC installé, version 5.5.1 et ouvert avec Sublime Text) :

Code: Select All Code

<?xml version="1.0" encoding="utf-8"?>
<system type="complex" access="777">
  <version type="unsignedInt" length="4">21</version>
  <cmdFlags type="unsignedInt" length="4">0</cmdFlags>
  <default_os_id type="hexBinary" length="8">000500101000400a</default_os_id>

  <default_title_id type="hexBinary" length="8">0005001010040200</default_title_id>

  <log type="complex" length="0">
    <enable type="unsignedInt" length="4">0</enable>
    <max_size type="unsignedInt" length="4">8388607</max_size>
  </log>
  <standby type="complex" length="0">
    <enable type="unsignedInt" length="4">0</enable></standby>
  <ramdisk type="complex" length="0">
    <cache_user_code type="unsignedInt" length="4">0</cache_user_code>
    <max_file_size type="unsignedInt" length="4">10485760</max_file_size>

    <cache_delay_ms type="unsignedInt" length="4">10000</cache_delay_ms>
  </ramdisk>
  <simulated_ppc_mem2_size type="hexBinary" length="4">00000000</simulated_ppc_mem2_size>

  <dev_mode type="unsignedInt" length="4">0</dev_mode>
  <prev_title_id type="hexBinary" length="8">0000000000000000</prev_title_id>

  <prev_os_id type="hexBinary" length="8">0000000000000000</prev_os_id>
  <default_app_type type="hexBinary" length="4">90000001</default_app_type>

  <default_device_type type="string" length="16" />
  <default_device_index type="unsignedInt" length="4">0</default_device_index>

  <fast_relaunch_value type="unsignedInt" length="4">0</fast_relaunch_value>

  <default_eco_title_id type="hexBinary" length="8">0005001010066000</default_eco_title_id>

</system>

Puis voilà TON system.xml (donc avec CBHC installé)(si tu as les deux à côté, tu pourras mieux comparer ) :

Code: Select All Code

<?xml version="1.0" encoding="utf-8"?>
<system type="complex" access="777">
  <version type="unsignedInt" length="4">21</version>
  <cmdFlags type="unsignedInt" length="4">0</cmdFlags>
  <default_os_id type="hexBinary" length="8">000500101000400a</default_os_id>

  <default_title_id type="hexBinary" length="8">0005000010198d00</default_title_id>

  <log type="complex" length="0">
    <enable type="unsignedInt" length="4">0</enable>
    <max_size type="unsignedInt" length="4">8388607</max_size>
  </log>
  <standby type="complex" length="0">
    <enable type="unsignedInt" length="4">0</enable></standby>
  <ramdisk type="complex" length="0">
    <cache_user_code type="unsignedInt" length="4">0</cache_user_code>
    <max_file_size type="unsignedInt" length="4">10485760</max_file_size>

    <cache_delay_ms type="unsignedInt" length="4">10000</cache_delay_ms>
  </ramdisk>
  <simulated_ppc_mem2_size type="hexBinary" length="4">00000000</simulated_ppc_mem2_size>

  <dev_mode type="unsignedInt" length="4">0</dev_mode>
  <prev_title_id type="hexBinary" length="8">0000000000000000</prev_title_id>

  <prev_os_id type="hexBinary" length="8">0000000000000000</prev_os_id>
  <default_app_type type="hexBinary" length="4">90000001</default_app_type>

  <default_device_type type="string" length="16"/>
  <default_device_index type="unsignedInt" length="4">0</default_device_index>

  <fast_relaunch_value type="unsignedInt" length="4">0</fast_relaunch_value>

  <default_eco_title_id type="hexBinary" length="8">0005001010066000</default_eco_title_id>

</system>

Perso, j'ai l'impression d'avoir fait une grande avancée,
Grâce à ton idée pour comparer nos sysfiles, j'ai expérimenté avec les utilitaires pour "administrer" la nand.
Mon prochain objectif est donc de dumper ma wii u brick avec mon fameux hardmod (rappel, il est ici : https://gbatemp.net/threads/successfully-dumped-wiiu-emmc-nand-with-hardmod.457165/ ) même si il y a des choses qui me rassurent pas trop, comme l'utilisation d'un teensy ou pas. (perso je compte pas l'utiliser).

Ce que je compte faire à présent est de monter/construire le hardmod, de dumper la mlc avec sdio_nand_manager (ici : https://github.com/dimok789/sdio_nand_manager/releases )
Et a priori je pourrais donc le lire avec Wii U Nand Extractor (https://gbatemp.net/threads/wii-nand-extractor.179630/ ) et dumper mes sauvegardes.
J'aurais là réussi mon objectif secondaire.

J'ai une autre question, Pour faire un dump complet de la nand, on utilise win32diskimager ou sdio_nand_manager (en dumpant tout ce qui est dumpable) ?
Si on réalise le dump avec win32diskimager, pourras-t-on toujours lire ce dump via Wii U NAND Extractor ?
Enfin pour restaurer la wii u si sauvegarde faite avec sdio_nand_manager il suffit de tout réinjecter ? Cela a le même effet que utiliser win32diskimager ?

Enfin, après avoir fait des dumps sûrs, je compte utiliser ton fameux "nandCbhcRemover" utilitaire compris dans wii u nand tools (https://gbatemp.net/threads/release-wii-u-nand-tools.465386/)

Mais peut-être que je vais un peu vite !
Es-ce que mes sources sont bonnes et les actions que je souhaite réaliser sont correctes ?!
Et merci encore pour tes aides pour résoudre mon PB.
@+

Malheureusement comme dit, si c'est sur la sysNAND, cela va être complexe sur une switch patchée même si tu as une sauvegarde de ta NAND. Et comme je ne veux pas t'induire en erreur car je n'ai jamais testé sur ces modèles, il te faut chercher le moyen de restaurer ta NAND si et seulement si, il existe. Ce que je doute mais je n'ai pas cherché plus que cela.

Faire une sauvegarde de la NAND est toujours plus que conseillé quelque soit la version de firmware avant de procéder au hack. Et si tu fais une mise à jour via ChoidujourNX, n’active pas le mode autoRCM qui modifie la NAND. Et à l’issu, tu feras une nouvelle sauvegarde de ta NAND (au cas où) avant de procéder au jailbreak. Les deux sauvegardes seront toujours utiles si problème de brick ou autre. Car si c’est le cas, tu pourras restaurer ta NAND pour ensuite mettre à jour ta console.

Sans mode autoRCM, tu vas griller des eFuses propres à la CM donc le downgrade sera compromis par le fait d’avoir griller des eFuses. Hekate permet le contournement de la vérification des eFuses si tu devais restaurer ta NAND pour ensuite mettre à jour.

Si tu fais une mise à jour au dessus de 4.0.1 et au dessus de 9.x.x, le port cartouche va se mettre à jour et donc griller deux eFuse propre à ce dernier différents de ceux de la CM. Il sera donc inutilisable en dessous du firmware 9.x.x. Il te faudra voir avec le patch NoGC seulement dispo avec Atmosphere pour en connaître les spécificités.

Pour ce qui est des jeux, il faut voir avec NSC_Builder pour éventuellement les patcher selon la version de firmware vers laquelle tu iras et ce qu’il demandera.

Tous les éléments sont abordés dans chaque FAQ des tutoriels qu’il faut lire !

Tu n’es pas sur le bon topic !
Ensuite le mieux est de restaurer ta NAND si tu as une sauvegarde propre. Ensuite, tu fais une mise à jour si la version de ta NAND est dans un firmware inférieur et que tu as fait la mise à jour en 9.x.x. Puis tu formates ta SD pour tout refaire.

Le fait d'être ban n’empêche pas la mise à jour du firmware sauf si Nintendo a encore revu sa politique.

Ça ressemble à un brick plutôt qu’autre chose ton histoire d’écran bleu. Et cela ne sera pas simple de lui redonner vie car pour simplifier cela, un dump de NAND serait facilitant.

Pour bricker une console ainsi, cela pourrait être dû à la mise à jour de la sysNAND avec mode autoRCM activé (ce qu’il ne faut surtout pas faire car non seulement ChoiDujourNX l’indique avant de l’utiliser mais en plus il le désactive par défaut donc soit cela a été forcé soit il s’agit d’une autre raison) Mettre à jour la sysNAND = perte de hack et autoRCM activé = Démarrage impossible sur une Switch patchée. Pour résumer, si la sysNAND a été mise à jour avec autoRCM activé sur une console patchée c'est fichu et tu ne pourras pas la redémarrer (je me répète sans doute). Et c’est valable sous emuNAND également mais différent avec ce qui suit en terme de solution de recours (sauf erreur).

En revanche et ce ne sera pas simple si c’est le cas, il te faudrait une seconde console « non patchée » (donc pas évident) pour mettre la NAND dessus. Il te faudra utiliser NXNandManager pour désactiver l’autoRCM (en prenant le BOOT0 de la NAND avec Memloader). Ensuite, il faudra mettre la NAND sur ta console. En faisant cela, le hack sera perdu pour utiliser Pegascape (mais la console démarrera à nouveau). Et ce n’est pas évident tout cela.

Et si tu ne veux pas perdre la possibilité de hack, et que tu as le dump de ta NAND (ce que je doute mais si c’est le cas, il fait qu’il soit correctement fait et non corrompu), tu peux la mettre sur une console « non patchée » (oui à nouveau et donc pas évident). Il te faudra utiliser Memloader et NXNandManager pour restaurer le dump de ta NAND d'origine et enfin remettre la NAND sur la console originale (je sais pas si je suis clair). C’est dans le cas où la mise à jour de la sysNAND n’a pas été faite et que l’emuNAND oui car les eFuses ne seront pas grillés. La console redémarrera et tu garderas la possibilité de hack (ce qui n'est pas possible si la sysNAND a été mise à jour).

Tu peux aussi regarder sur la Toile pour debricker/réinitialiser une console.

Je n’ai pas encore eu cela donc difficile de détailler davantage et il faut connaître le moyen sur une console patchée car l’injection est bloquée en RCM donc à voir si tout cela est vraiment possible.

https://www.modconsoles.fr/forums/topic ... rick-cbhc/

https://gbatemp.net/threads/successfull ... od.457165/

https://www.reboot.ms/forum/threads/gui ... store.530/

il y avait aussi un site qui te faisait la pose et laissait a accès en perçant la coque de la console.

Nan mais quoi tu as fait
Ce qu’il te reste est la sauvegarde de ta NAND (tu me diras, c’est primordiale). Mais avant de la restaurer et si tu as tout supprimé sur ta SD, pas besoin de la restaurer sauf si ta console ne répond plus (ce que je n’espère pas pour toi).

Si elle démarre normalement, tu as juste à refaire et préparer ta SD à nouveau tout simplement. Et pour terminer refaire le jailbreak.